nit: const char **list ?

I did this to match the signature of dup_list, but I don't really mind either way.

how is this "quad"?

I'm using the term quadoption from Mutt, but you're right that this might not be the best name.

Actually this looks triopt, as it has three values.

In github.com/moby/buildkit we call this BoolOrAuto.

I know it has three values, I was referring to "quadoption" as a term in Mutt (see §26.1 of the Mutt manual). But maybe defaultbool_t is a better name. I'll fix it once I can fix the lib/ build issues.

Please add a comment about that no uid flag is valid atm

Technically +1 shouldn't be needed here right? Each entry is followed by either comma or \0, and you add +1 to the length of each entry as you add up.

Interestingly, the loops are simpler if we leave a trailing comma, so that a CSV would look like a,b,c,\0. It is technically incorrect as a CSV --as you have a trailing empty element--, but we do support such CSVs elsewhere, so we could keep the +1.

This isn't really performance critical, but re-calculating j at each iteration here is unnecessary.

Oh, but you're using strncat which doesn't give you the printed length, I see :)

We now have stpecpy(), which is designed precisely with this in mind.

iiuc this is a gnu extension, probably not safe for shadow to use, so please make it options ? options : ""

We have recently embraced this GNU extension.

Hm, is this the right place to put this kind of thing though? Maybe it is, but:

The only case I know of for deny-setgroups is when an administrator has placed a user in a group with a negative acl, to prevent that user from accessing some resource.

In that case, does it make more sense to place a sort of "group_locked" option on the group itself in /etc/group? Then when newgidmap runs, it checks whether the target pid is in any locked group, and if so sets deny_setgroup.

Placing the deny/allow_setgroup variable in the gid mapping seems a step removed, and might cause an admin to not notice that "hey, the user being allowd to grab those gids should have been locked into group nos3critdocs.

Hmm, I hadn't though of this point.

You're quite right that most users of negative ACLs are done with groups (and I think it does make intuitive sense to be able to say "if you are in a bad group then you cannot use setgroups"), but I have a couple of questions about edge cases:

• Should an administrator be able to override this decision for particular users or groups? Should that also be in /etc/groups (or /etc/passwd)?

• What if it's a numeric group (so not one registered in /etc/groups)? Is the solution to just tell people "tough luck, you should register your group"?

• This is a bit of an edge condition (and is an edge condition that actually isn't really easy to handle with the current implementation either), but how will this affect containers on the system that are also using group blacklisting? While /etc/sub* are global, if you have containers using allocated portions of the UID/GID space then you would expect that a user shouldn't be able to use newgidmap to drop the negative ACLs for a different group set than the one you are joining? Now, this is quite a weird case because it would require you to have a quite strange ACL setup -- so maybe this is a use case we don't care about?

Should an administrator be able to override this decision for particular users or groups? Should that also be in /etc/groups (or /etc/passwd)?

I don't really think so, as you either want to deny the group certain access or you don't, but my gut says there are more subtle cases. So let's say yes.

What if it's a numeric group (so not one registered in /etc/groups)? Is the solution to just tell people "tough luck, you should register your group"?

I think requiring a name makes sense. Do you?

how will this affect containers on the system that are also using group blacklisting?

Hmm - that applies to your approach too right?

It really seems like this requires a new kernel functionality to make the most sense - a new per-process 'lockedgrp' from which groups can never be removed. Otherwise all we can really do in the parent container is say "never let the child container do a setgroup" (right? or have i confused myself on this topic once again?)

Please use stpecpy() instead. We have forbidden strncat() with string input; we only allow it with [[gnu::nonstring]] input --that is, utmp(5) members--.

With stpecpy() --which is defined in lib/string/--, it would be:

char  *p, *e;

[...]

p = comma;
e = comma + commalen + 1;
for (int i = 0; NULL != list[i]; i++) {
	p = stpecpy(p, e, list[i]);
	p = stpecpy(p, e, ",");
}

if (p == NULL) {
	free(comma);
	return NULL;
}

return comma;

Or, since we know there won't be truncation, we can just use stpcpy(3) from libc.

char  *p;

[...]

p = comma;
for (int i = 0; NULL != list[i]; i++) {
	p = stpecpy(p, list[i]);
	p = stpecpy(p, ",");
}

return comma;